
APAR= II09599
ODBC TROUBLESHOOTING - CA400WIN95 CA400WIN CA400OS2OPT  V2.0
  1.0 CONNECTIVITY PROBLEMS:  2.0 HOW TO LOCATE YOUR JOB
ODBC Troubleshooting - CA400WIN95 CA400WIN CA400OS2OPT  V2.0
============================================================
                                         LAST UPDATE 7/18/96

CONTENTS
========
1.0 ....................... Unable to connect to the AS/400
2.0 ............................ How to locate the ODBC job
3.0 ......................................... Common Errors
4.0 ..................... Reporting problems to IBM Support
5.0 ...................... Diagnostic and Performance Tools
6.0 .............................................. Security
7.0 ...................................... Other References


1.0  Unable to connect to the AS/400
====================================

Understanding the Database Server Program
-----------------------------------------
Each Client Access function communicates with a program
that runs on the AS/400.  This program is referred to
as the 'host server' program.  Several host programs are
used for database serving depending on the type of
connectivity. For example:

 - SNA (or 802.2) connection: QIWS/QZDAINIT
 - TCP/IP and IPX socket connection: QIWS/QZDASOINIT

The Client Access for windows 95 product is the first
member of the Client Access family that can run across
multiple protocol stacks: SNA (or 802.2); IPX (novell);
and TCP/IP.  When troubleshooting this client, you must
be aware of the type of connectivity.  All other clients
(such as the windows 3.1 client) use only SNA.  ANYNET
should be considered SNA.

Under normal conditions these programs are evoked
transparently; i.e. the user needs to take no action
except to verify the proper subsystems and communication
protocols are running.  See SC41-3740 OS/400 Server
Concepts and Administration for details on administration of
host server jobs.

Checking Server status (TCP/IP and IPX connections only)
--------------------------------------------------------
The Client Access for Windows 95 product has a special
command to verify status of host servers:

    CWBPING systemname protocol
    where systemname is the name of the AS/400 system
    and protocol is IP or IPX, the default is IP.

The command should return the following:

     pinging server Port Mapper successful
     pinging server as-central successful
     pinging server as-database successful
     pinging server as-dtaq successful
     pinging server as-file successful
     pinging server as-netprt successful
     pinging server as-rmtcmd successful
     pinging server as-signon successful

If the servers are not active or you are using a SNA
connection then continue with the next section.

Verify the proper subsystems are running
----------------------------------------
TCP/IP and IPX connected ODBC jobs (QZDASOINIT) will run in
the QSERVER subsystem.  SNA connected ODBC jobs (QZDAINIT)
will normally run in QSERVER.  Verify that this subsystem is
running.  The Client Access for Extended DOS router and
many OEM SNA connections (such as Netware for SAA) can
only use the mode QPCSUPP and will therefore run the ODBC
job in QCMN.

Because of changes made to subsystem descriptions in V3R1
and later, the QSERVER subsystem may need to be manually
started.  To do this, simply issue the following command:

   STRSBS QSERVER

To have the subsystem start automatically at IPL, then
modify the AS/400 IPL Start up procedure (the default is
QSYS/QSTRUP) to include the STRSBS QSERVER command.

In addition to subsystem QSERVER,
subsystem QSYSWRK must be running for TCP/IP and IPX
connections.

Verify that the proper prestart jobs are running.
-------------------------------------------------
IBM ships the QSERVER subsystem configured to use prestart
jobs to improve performance at job initialization/start up.
When prestart jobs are configured in the subsystem, the job
MUST be active to connect.  The prestart job used depends
on the type of connection:

- SNA (or 802.2) connection
    QZDAINIT - Server program

- TCP/IP and IPX socket connection
    QZDASOINIT - Server program
    QZDASRVSD  - Server Daemon program

To verify a prestart job is running:

      WRKSBSJOB QSERVER

The appropriate prestart jobs should be active:

  Job         User    Type    -----Status-----
  QZDAINIT    QUSER   PJ    ACTIVE    (SNA connection)
  QZDASOINIT  QUSER   PJ    ACTIVE    (socket connection)
  QZDASRVSD   QUSER   PJ    ACTIVE    (socket connection)

Prestart jobs do not display in WRKACTJOB unless a
connection is already active.  You must use F14 - Include
from the WRKACTJOB panel for prestart jobs to display.

Further TCP/IP and IPX considerations.
--------------------------------------
Verify that TCP/IP or IPX is started with the following
command:

   NETSTAT *CNN

Use the commands STRTCP or STRIPX to start the desired
protocol if it is not running.

Verify the necessary daemons are running by browsing the
information returned from the NETSTAT *CNN command:

   Remote           Remote     Local
   Address          Port       Port       Idle Time  State
   *                *          as-cent >  000:09:31  Listen
   *                *          as-signon  000:09:41  Listen
   *                *          as-svrmap  002:57:45  Listen
   *                *          as-data >  002:57:45  Listen

Use the command STRHOSTSVR SERVER(*ALL) to start them
if necessary.

- Verify QZDASRVSD, the ODBC socket daemon, is running.

   o as-database should be in the Listen State
   o WRKJOB QZDASRVSD should be used to check the joblog of
     the daemon for any error messages.

- Verify that socket daemon QZSOMAPD is running in QSYSWRK
  subsystem.

   o as-svrmap should be in the Listen State as shown by
     NETSTAT *CNN.
   o WRKJOB QZSOMAPD should be used to check the joblog of
     the daemon for any error messages.

The PC locates the socket used by the database server by
connecting to the server mapper socket.  It retrieves
the socket used by as-database.  It
then connects to the proper socket which is being
monitored by the file server daemon, QZDASRVSD.
The server daemon will attach the client's
connection to a QZDASOINIT prestart job in QSERVER.
After validating the user profile and password and
swapping the user profile into the prestart job, the job
will run similar to the QPWFSERV jobs of an SNA connection.
If this is the first connection made to the as/400 for this
PC, then two other servers are used: Central server for
licensing and Signon server for userid/password validation.

Verify that the host server program product is installed.
---------------------------------------------------------
The Database Server is installed as part of the operating
system.  If all PCs are still unable to connect to the
server or the QSERVER subsystem is not on the  system, then
verify that product xxxxSS1, option Host Servers is
installed where xxxx is the OS/400 lpp (license program
product) for the version current version of OS/400.

2.0 Identifying the ODBC job and joblog
=======================================

How to find your Job
--------------------

This can sometimes be challenging as WRKACTJOB shows the
prestart jobs as all running under QUSER.  You must display
the joblog to find the user profile the job is actively
running under.

For a SNA connection, there is an easier method.  Use Work
with Configuration status on the PC's APPC device.  All
jobs allocated for the device will appear there.  To do
this, type the following  command:

   WRKCFGSTS CFGTYPE(*DEV) CFGD(LOCNAME)

Where LOCNAME is the Local Location name of your PC.
To find this value, look up the LOCALLUNAME parameter.
This parameter is part of the SNA router configuration.
For the Client Access for Windows 3.1 router it is
contained in the WINDOWS NSD.INI file.
Keep in mind that the AS/400 may add a '0x' to the
end of the name if it detects a damaged controller.

The following will be displayed:

  QSERVER   ACTIVE/TARGET     QZDAINIT    QUSER    123456

(Where 123456 is your Job ID.)

or if another mode description is used&colon.

  QPCSUPP   ACTIVE/TARGET     LOCNAME   USERID     123456

(Where LOCNAME is your Local Location name, USERID, is the
user id that you used to sign-on to the router with, and
123456 is your Job ID.)

For a TCP/IP or IPX connection, the following command may
help locate the ODBC job:

   WRKOBJLCK OBJ(userid) OBJTYPE(*USRPRF)

"userid" is your user profile used for the ODBC connection.

How to generate a joblog
------------------------

Some internal errors cause the job to immediately end.
To isolate these types of errors, the database server job
needs modified so that a joblog is generated.  A CHGJOB
command can be used to modify an existing job or the job
description can be modified to change all new jobs.  To
modify the default job description enter the following
command prior to recreating the error:

      CHGJOBD JOBD(QDFTJOBD) LOG(4 00 *SECLVL)

When finished, execute this command to change it back:

      CHGJOBD JOBD(QDFTJOBD) LOG(4 00 *NOLIST)

If the job description is not changed back other jobs on
the system will be forcing joblogs to be written and system
storage will fill up rapidly.

How to find the joblog
----------------------

Type the following command and prompt for parameters
using F4:

      CHGPRTF FILE(QPJOBLOG)

Press F10 and Page down until to a field called Spooled
Output Queue.  This is the OUTQ that the joblog will be
written to.  By default it is QEZJOBLOG in library QUSRSYS.
Record the file and library name of the output queue, and
then run the following command to work with all of the
entries in the output queue:

      WRKOUTQ QEZJOBLOG

Press F16 to move to the bottom of the list.

An alternative way of finding the joblog is to use the
WRKSPLF command.  If running under QSERVER, then the USERID
is always QUSER.  If running under another subsystem, then
the USERID will be the one used for the router sign on.
The following command can be used:

      WRKSPLF USERID

Where USERID is QUSER or your USERID.
.
.
*** This information continues in II09603 ***
